1. Field of the Invention
The present invention relates generally to a multi-thread processing apparatus designed to call single thread programs from a multi-thread program executing a plurality of threads in parallel and to run the single thread programs called, and a multi-thread processing method as well as a computer readable record medium having thereon stored a multi-thread processing program. More particularly, it relates to a multi-thread processing apparatus ensuring a call of the same single thread program by a plurality of threads, and a multi-thread processing method as well as a computer readable record medium on which a multi-thread processing program is stored.
2. Description of the Related Arts
In a program operable in multi threads such as Hot. Java, a so-called multi-thread program, in cases where faster processing of a certain thread is achieved by using a single thread program such as the existing COBOL which is present in the form of a dynamic library, the existing single thread program has hitherto been called for operation from the multi-thread program.
FIG. 1 illustrates the case where the multi-thread program on a server calls the existing COBOL program by use of a remote method invocation (RMI) for the run thereof. When accepting a method call (RMI call) from clients 120-1 and 120-2, an RMI server application 100 acting as the multi-thread program generates a root thread 114 as a main thread and then generates threads 116-1 and 116-2 and runs the same. In this manner, the PMI server application 100 generates a plurality of threads in response to the method call and executes them in parallel, with the result that it acts inevitably as a multi-thread program. In such a case, the user is not able to control the generation of the threads 116-1 and 116-2. For this reason, the threads 116-1 and 116-2 arbitrarily call and run a single thread program 118 written in COBOL program or the like as the existing resources.
In the case of calling and running the single thread programs from the multi-thread program, however, the following problems will take place. First, the single thread program 118 may sometimes use such resources as static variables on the assumption that one process consists of one thread. If such a single thread program 118 is operated in the multi thread allowing accesses of a plurality of threads, the accesses to the resources such as the static variables may compete, resulting in a possible abnormal action of the single thread program.
FIG. 2 illustrates a problem which will occur when an access to the static variable of the single thread program has been made by functions of the threads 116-1 and 116-2 of FIG. 1. The threads 116-1 and 116-2 of FIG. 1 are executed in parallel but in asynchronism to call the single thread program 118 separately. At that time, the functions Awrap fl (args)@ and Awrap f2 (args)@ of the threads 116-1 and 116-2, respectively, make accesses to the static variable Aptr@ of the single thread program 118. For example, a call by the thread 116-1 allows a memory area 138 for the static variable ptr to be allocated to a data area 136 within f(1) of a thread corresponding area 134-1 of a process area 132 allocated in a main storage 130 of FIG. 2. An access to the area 138 allocated to the static variable ptr is then made and the area 138 is deallocated previous to the resetting of f10. Similarly, a call by the thread 116-2 also allows the allocation of the memory area 138 for the static variable ptr within f20 of a thread corresponding area 134-2, after which an access is made to the area 138 allocated to the static variable ptr, the area 138 being deallocated prior to the resetting of f20. Due to the asynchronism in execution of the single thread program 118 by the threads 116-1 and 116-2, the accesses of the functions f10 and f20 to the static variable ptr are also executed in parallel but in asynchronism. For this reason, immediately after the allocation of the memory area 138 to the static variable ptr by the function f10 of the thread 116-1, there will again occur the allocation of the memory area 138 to the static variable ptr by the function f20 of the thread 116-2. At that time, as a result of the access to the area 138 for the static variable ptr by the function f10 of the thread 116-1, there will be no area intended by the allocation by the function f20 of the thread 116-2, resulting easily in an abnormality such as memory overrun, leading to an abnormal end of the program. In case of execution of the single thread program 118 by the plurality of threads 116-1 and 116-2, the single thread program 118 may not necessarily be executed in the order of call by the threads 116-1 and 116-2, so that the order of actions will not be assured. Thus, the result of execution may possibly depart from the intention of the user.
FIG. 3 illustrates the case where the single thread program as the existing resources is called from applets executed in parallel on the browser. When applets 146-1 and 146-2 of a WWW server 140 are downloaded by the threads 116-1 and 116-2 generated on a browser 144 of a client 142, the plurality of applets 146-1 and 146-2 are executed in parallel on the browser. In this case as well, the user is not able to control the generation of the applets 146-1 and 146-2. For this reason, the applets 146-1 and 146-2 arbitrarily call and run the single thread program 118 written in COBOL program or the like as the existing resources. As a result, any competitive accesses may arise to the resources such as the static variables shown in FIG. 2, so that the single thread program may operate in an abnormal manner.
In order to solve such a problem which may occur when the existing single thread program is called for the running from the multi-thread program, it may be envisaged that a different process is generated upon the call of the single thread program from the multi-thread program so that the single thread program can be run therein. However, the generation of the new process may often necessitate the generation of a data area, with a greater load resulting in a poor performance. It may also be conceivable that the existing single thread program is remade into a multi-thread program. However, remaking the existing single thread program into the multi-thread program will need a number of process steps, resulting in a lowered efficiency of development.